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(57) ABSTRACT 

A certification or signature is incorporated in a computer 
program, an executable file, or code to assure its authenticity 
and integrity, particularly for receiving it over an open 
computer network like the Internet. The executable file may 
be of any executable form, including an executable or 
portable executable .exe file format, a .cab cabinet file 
format, an .ocx object control format, or a Java class file. The 
certification includes a keyed source confirmation with a 
secure representation of the executable file. In an 
embodiment, the certification is referenced in a header of the 
executable file, the reference including a pointer to the keyed 
source confirmation and an indication of the size of the 
keyed source confirmation. 
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EMBEDDING CERTIFICATIONS IN ment that can be visited. As a consequence, software distri- 

EXECUTABLE FILES FOR NETWORK bution over an open network is susceptible to corruption by 

TRANSMISSION a party impersonating a proper software distributor or by the 

FIELD OF THE INVENTION , " * * ^ 

This invention relates generally to obtaining computer One approach to addressing this problem is to create a 
software over an open computer network like the Internet protective and padded virtual machine on the software 
and, in particular, to identifying the source of such software. recipient's computer. Such a virtual machine, which is often 

RAnrrumiMn amt> cinuiuADv nmir referred to as a playpen or sandbox, allows untrusted, 

BACKGROUND ^^UMMARY OF THE 10 p^iy ma li c ious code to be executed without fear that it 

INVENTION could cause any unauthorized or unwarranted actions. This 

The Internet is a well known, global network of coopera- approach is an outgrowth of the security architecture in 

tively interconnected computer networks. The world wide existing computer operating systems. A problem with this 

web portion of the Internet is a collection of server com- approach is that it is extraordinarily difficult to create a 

puters (referred to as "sites**) on the Internet which store 15 sandbox that is actually secure against malicious code. 

HTML documents that can be publicly accessed by com- Unexpected security holes are commonly discovered in 

puter uses having a connection to the Internet There are supposedly secure operating systems that use this method, 

many such world wide web sites on the Internet. But even assuming that this difficulty could be overcome, 

Software, generally known as "Internet browsers,** are a fundamental quandary with the sandboxing approach is 

now in wide-spread use for retrieving (also known as mat mere is a very strong tension between creating a 

"downloading") and viewing electronic documents in hyper- sandbox safe enough to run perhaps malicious code, but yet 

text markup language (HTML) format from the world-wide with sufficient access to system resources to be capable of 

web. Originally, these HTML documents were simply performing useful operations. For example, sandboxed code 

ASCII coded character files generally consisting of text and - mat is allowed to make network connections off of a host 

HTML "tags" that specify formatting of the document, links machine (e.g., TCP, FTP, EMail, or otherwise) should not 

(referred to as "hyper-links") to related documents on the nav e access to any information on the machine that is to be 

network, and other files that contain information (e.g., kept private. As other examples, some system utilities such 

sound, images, video, etc.) to be combined into the docu- *s a disk defragmenter or an indexing utility that locates the 

ment. Typical HTML documents found on the world wide ^ l° s * documents on a hard disk would likely be inoperable as 

web include both text and tags specifying files for several sandboxed code. A sandbox that successfully protected 

images that are to be displayed with the text. In use, browser against the damage these utilities might possibly cause 

software allows a user to navigate (also known as would prevent them from carrying out their intended pur- 

"browsing") between documents and sites on the world- pose. 

wide web. ^ A certification or signing method ensures the authenticity 

More recently, the files that browsers are capable of ant * integrity of a computer program, an executable file, or 

accessing and utilizing include executable files such as, for code received over a computer network. The method is used 

example, OLE (object linking and embedding) controls and Dv a publisher or distributor to "sign" an executable file so 

JAVA applets. These executable files were at first used to it can be transmitted with confidence to a recipient over an 

enhance the image characteristics of an HTML document by 4Q °P eD network like the Internet. The executable file may be 

adding features that move or have other changing image °f executable form, including an executable or portable 

characteristics. Moreover, it is expected that the functional- executable .exe file format, a .cab cabinet file format, an .ocx 

ity of such executable files will increase to include a wide object control format, or a Java class file, 

range of applications and application components. In addi- The code signing method assures the recipient of the 

tion to browsers utilizing executable files, the marketing and 45 identity of the publisher as the source of file (i.e., its 

distribution of computer software is increasingly utilizing authenticity) and that the file has not been modified after 

network-based distribution rather than the traditional distri- being transmitted by the publisher (i.e., the integrity of the 

bution of computer readable media such as magnetic file). As a result, the code signing method allows an execut- 

(floppy) diskettes or optical (CD-ROM) disks. able file to be transmitted over open computer networks like 

A danger in wide-spread distribution of executable files so toe Internet with increased certainty in the identity of the 

over open networks like the Internet is an increased risk of source of the file and minimize d risk of contracting a 

contracting computer viruses or other malicious executable computer virus or other malicious executable computer files, 

computer files. Computer viruses have long been a scourge In one implementation, the method includes determining 

of computer owners and operators because of the relative a cryptographic digest or "hash" of the executable file and 

ease of contracting many viruses and the potentially devas- 55 forming a publisher signature with the cryptographic digest, 

taring damage that viruses can cause. A common and effec- The publisher digital signature may also include an identi- 

tive defense to computer viruses has been to install execut- fying name of the executable file and possibly a link or 

able files only from computer readable media that are known hyperlink to a description of the executable file. The pub- 

to be virus-free, such as the original media on which lisher signature is formed with a public-private key signature 

software are distributed by a manufacturer or software 60 algorithm, such as the RSA public key cipher, as is known 

distributor or publisher. in the art 

Confidence in the authenticity of the original media is A publisher digital certificate is attached to the publisher 
established by conventional marketing devices such as signature. The publisher digital certificate is issued by a 
packaging, trademarks, the reputation of retailers offering certification authority or agency to authenticate the identity 
the software, etc. Software that is distributed over an open 65 of the publisher issuing the publisher signature. The pub- 
network like the Internet does not have identifying lisher digital certificate is a cryptographic certificate that 
packaging, fixed original media, or even a retail establish- includes the software publisher's name, a public key corre- 
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sponding to a private key used by the publisher to sign the FIG. 2 is a block diagram of the computer system of FIG. 

file, an expiration date (or vaHdity period) of the certificate, 1 connected to a remote computer network (eg the 

and possibly a link or hyperlink to the certification agency, Internet) for locally browsing electronic documents residing 

including a statement of its certification policy and its at a remote computer site 

identifier (e.g., trademark). The digital certificate is c i * « a- - .„ . 

encrypted with a private key corresponding to a widely HG 3 a fiagmm representing a code certification 

known and readily available certification agency public key °r signing method for ensuring the authenticity and integrity 

For example, the certification agency public key may be on of a ""P 1 "*" program or an executable file received over a 

or linked to a key that is on the recipient's computer in computer network. 

association with a browser application or another software PIG. 4 is a schematic representation of an executable file 
application or the operating system. Alternatively, the cer- 10 w ^ a publisher signature according to the present iden- 
tification agency public key may be posted on an open tion. 

network like the Internet, or otherwise published. FIG. 5 is a schematic representation of a root public key 

This certification of the executable file or code is con- incorporated into a browser application. 

firmedorrea^ FIG. 6 is a flow diagram representing a publisher fupa- 

thepubl^erssign^ 5 

ing the digital certificate with the certification agency public CTr , - :u m ^^. , , 

key, thereby assuring the authenticity of the software pub- ™ 1 ^* at f ™ exemplary digital certificate dialog 

Usher. A cryptographic digest or hash is determined for the rcndercd ° n a display screen to provide a user with a simple 

code as it is received. The digest is compared to the digest ^"Part identity confirmation of the publisher of an execut- 

inchided in the publisher signature. A match between the 20 aWe file " 

digests confirms the integrity of the code. A dialog is then ^G. 8 is a diagrammatic illustration of a meta-agency 

rendered by the recipient computer indicating who is pro- digital certificate by which a higher-level or meta-agency 

viding the code and the certification agency that has authen- grants a certification agency authority to issue publisher 

ticated the identity of the publisher. digital certificates. 

The publisher digital certificate and the publisher signa- 25 PIG. 9 is a flow diagram of an agency/meta-agency 

ture together form a keyed source confirmation with a secure certificate decoding method. 

representation of the executable file. The source confinna- FIG. 10 is a flow diagram of a digital certificate revoca- 
tion is keyed in that it (or a portion of it) is encrypted with tion method, 
a key, or includes a key, or both. The described implemen- ^ 

tation of pub&her digital certificate and the publisher sig- 30 DETAILED DESCRIPTION OF EMBODIMENT 

nature as a source confirmation is both encrypted with a key Referring to FIG. 1, an operating environment for an 

and includes a key. illustrated embodiment of the present invention is a com- 

In one embodiment, the certification is referenced in a P uter system 20 with a computer 22 that comprises at least 

header of the executable file, the reference including a one ^8° s P eed processing unit (CPU) 24, in conjunction 

pointer to the keyed source confirmation and an indication of 35 a memory system 26, an input device 28, and an output 

the size of the keyed source confirmation. The header device 30. These elements are interconnected by at least one 

reference functions to identify the location of the keyed DUS structure 32- 

source confirmation so that it is not included in the crypto- The illustrated CPU 24 is of familiar design and includes 

graphic digest or hash that is determined for the code 411 ALU ^4 for performing computations, a collection of 

received at the recipient's computer. In addition, other 40 registers 36 for temporary storage of data and instructions, 

components of the executable file or code may be excluded aD d a control unit 38 for controlling operation of the system 

from the hash computed at the recipient's computer, as well 20. The CPU 24 may be a processor having any of a variety 

as the original hash of the file. As a result, the hash that is °f architectures including, but not limited to, Alpha from 

computed can, if the executable file remains unchanged Digital, MIPS from MIPS Technology, NEC, IDT, Siemens, 

except for the excluded information, match the original 45 aDO * others, x86 from Intel and others, including Cyrix, 

cryptographic digest for the file. AMD, and Nexgen, and the PowerPC from IBM and 

This two-level identity confirmation provides the recipi- Motorola, 

ent with a concise, simple assurance of the authenticity and The memory system 26 generally includes high-speed 

integrity of the downloaded code or executable file. By maul memory 40 in the form of a medium such as random 

authenticating the identity of the publisher rather than the 50 access memory (RAM) and read only memory (ROM) 

actual code, the certification agency need not authenticate semiconductor devices, and secondary storage 42 in the 

the code being signed by the publisher. This allows the f° rm of long term storage mediums such as floppy disks, 

certification agency to authenticate the identity of a re la- naf d disks, tape, CD-ROM, flash memory, etc. and other 

tively large number of software publishers. If present, links devices that store data using electrical, magnetic, optical or 

to the certification agency and a description of the code 55 other recording media. The main memory 40 also can 

allow the recipient to obtain additional information about the include video display memory for displaying images 

code and the agency's certification policies before choosing through a display device. Those skilled in the art will 

to run or accept the code. recognize that the memory 26 can comprise a variety of 

Additional features and advantages of the invention will alternative components having a variety of storage capaci- 
be made apparent from the following detailed description of 60 t ^ es - 

an illustrated embodiment which proceeds with reference to The input and output devices 28, 30 also are familiar. The 

the accompanying drawings. input device 28 can comprise a keyboard, a mouse, a 

BRIEF DESCRIPTION OF THE DRAWINGS flf^jT^™ ^ V^ ro P hone >' ete ^ °*P ut 

device 30 can comprise a display, a printer, a transducer 

HG. lis a block diagram of a computer system that may 65 (e.g., a speaker), etc. Some devices, such as a network 

be used to implement a method and apparatus embodying of interface or a modem, can be used as input and/or output 

the present invention. devices. 
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As is familiar to those skilled in the art, the computer having other data formats (e.g., Microsoft Word documents, 

system 20 further includes an operating system and at least etc.) from the computer 20 or remote computer 58. In 

onej application program. The operating system is the set of conformance with HTML, the illustrated document 60 can 

software wh,cb controls the computer system's operation incorporate other additional information content 62, such as 

r^ e f ( ^ 0D( £?*T eS -^Wjicahon programs s images, audio, video, executable programs, etc. (hereafter 

the set of software that performs a task desired by the user, sim , „ 62) M ^ ^t^L remote com 

S ,T. P " LT UrCCS V^'V^S ^ 0per " puter 58. ^document 60 and images 62 arl s3 as fl« 

a ting system. Both are resident in the illustrated memory ■„ „ r . , ... 4 -« at^.«j©in» 

*!„ ^ tt. , , * in a file system of the remote computer 58. The document 60 

system 26. The operating system may employ a graphical - t ... ^ „ , u^umtm w 

♦ j- ■ j i fu, o^uiuu incorporates the images 62 using HTML tags that specifv the 

user interface where the display output of an application , n i~.,t\L ^ «i .u i . . tuc 

~ • „ « i ✓ 10 locatlon of files or other Internet resource containing the 

program is presented in a rectangular area (sometimes ^ OQ me Intemet 52 . g 

referred to as a "Window") on the screen of the output Jt . - t , 

device 30 and is also multi-tasking (allowing application , When used for browsing documents, the illustrated 

programs to execute computing tasks in multiple threads) b "? WSer ^phys me document ra a 68 or rectan- 
such as Microsoft's Corporation's Windows 95 or Windows 1C ^ area of tbe computer's display 30 allocated to the 

NT operating system, IBM's OS/2 Warp operating system broWSer by * e °P eraUn S s y stem - 11,6 illustrated window 68 

Apple's Macintosh System 7 operating system, X-Windows, a &ame ™> adocument display area 72, and user 

etc interface controls 74. The browser displays the document 

In accordance with the practices of persons skilled in the ^ ^ 3163 72 of me 68 

art of computer programming, the present invention is 20 nG 3 B a flow dag*™ representing a code certification 
described below with reference to acts and symbolic repre- 0r agQmg method 100 for ensurin g mc authenticity and 
sentauons of operations that are performed by computer m £ grity of a com P uter Program, code, or an executable file 
system 20, unless indicated otherwise. Such acts and opera- 11X2 reccivcd over computer network 52, or any other 
lions are sometimes referred to as being computer-executed computer cetwork - Method 100 is used by a publisher or 
It will be appreciated that the acts and symbolically repre- 25 distnbutor t0 executable file 102 so it can be trans- 

lated operations include the manipulation by the CPU 24 of mitted seaatil y to a recipient over an open network like the 
electrical signals representing data bits which causes a ^ternet. Executable file 102 may be of any executable form 
resulting transformation or reduction of the electrical signal ™cludrag, for example, an .exe executable or portable 
representation, and the maintenance of data bits at memory **?*tibk file format, a .cab cabinet file format, an .ocx 
locations in memory system 26 to thereby reconfigure or 30 object contro1 ioun ^ or a Java class me fonnat - 
otherwise alter the computer system's operation, as well as Code si&nmg method 100 assures the recipient of the 
other processing of signals. The memory locations where identity of the source of file 102 (i.e., its authenticity) and 
data bits are maintained are physical locations that have mat me ^ was DOt modified after it was transmitted by that 
particular electrical, magnetic, or optical properties cone- source (i.e., the integrity of file 102). As a result, code 
sponding to the data bits. 35 sigmng method 100 allows an executable file to be trans- 

FIG. 2 shows a browsing environment 50 in which milted over °P cn computer networks with increased cer- 
computer 20 (also shown in FIG. 1) runs software, referred m me identit y of ^ source of the file and mimmized 

to herein as a "browser," for unified browsing of electronic of contracting a computer virus or other malicious 

documents and other data from local sources (e.g., the executable computer files. 

secondary storage 42 of FIG. 1) and from a remote computer 40 Process block 104 indicates that a cryptographic digest or 
network 52. The browser can be integrated with the oper- "bash" 106 (FIG. 4) of executable file 102 is obtained or 
ating system software, or can be separate application soft- computed. Standard hash functions are available, such as 
ware. The illustrated remote computer network 52 is the 5 " "SHA". These functions take a variable-length 

Internet, which is described in the Background and Sum- m P ut string and convert it to a fixed-length output string of 
mary of tbe Invention above. In the illustrated browsing 45 bits or more (called a cryptographic digest). This 
environment 50, the computer 20 connects to the computer fixed-length string "fingerprints" the file by producing a 
network 52 over a telephone line 54 with a modem 56. Other value mat indicates whether a file submitted for download 
physical connections to the computer network alternatively matches the original file. Hashing functions and the values 
can be used, such as an ISDN, Tl or like high speed mev generate are secure in that it is computationally infea- 
telephone line and modem, a television cable and modem, a 50 s *°l e to a l ter a document without changing its hash, 
satellite link, an optical fiber link, an Ethernet or other local Process block 108 indicates that a publisher signature 110 
area network technology wire and adapter card, radio or (FIG. 4) is formed with cryptographic digest 106. Publisher 
optical transmission devices, etc. The invention can alter- signature 110 may also include an identifying name 112 of 
natively be embodied in a browsing environment for other executable file 102 and a link or hyperlink 114 to a descrip- 
public or private computer networks, such as a computer 55 fion of executable file 102. 

network of a commercial on-line service or an internal In one embodiment, publisher signature 110 is formed 
corporate local area network (LAN), an intranet, or like with a public-private key signature algorithm, such as the 
computer network. RSA public key cipher according to the PKCS #7 format 

Documents for browsing with the illustrated browser can promulgated by RSA Laboratories, PKCS#7: Cryptographic 
reside as files of a file system stored in the computer's 60 Message Syntax Standard. Version 1.5, November, 1993. 
secondary storage 42 (FIG. 1), or reside as resources at a Public key algorithms use a confidential private key to 
remote computer 58 (also referred to as a "site") connected encrypt information and a freely available public key to 
to the computer network 52, such as a world-wide web site decrypt or validate the encrypted information. Such encryp- 
on the Intemet. The illustrated document 60 residing at the tion is secure because is it computationally infeasible to 
site 58 conforms with HTML standards, and may include 65 determine the private key from the public key. 
extensions and enhancements of HTML standards. Process block 120 indicates that a publisher digital cer- 
However, the illustrated browser also can browse documents tificate 122 (FIG. 4) and publisher signature 110 are attached 
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or appended to or incorporated to executable file 102. 
Publisher signature 110 and publisher digital certificate 122 
together form a keyed source confirmation with a secure 
representation of the executable file. The source confirma- 
tion is keyed in that it (or a portion of it) is encrypted with 5 
a key, or includes a key, or both. A source confirmation with 
publisher signature U0 and publisher digital certificate 122 
as described is both encrypted with a key and includes a key. 

Publisher digital certificate 122 is issued by a certification 
authority or agency to authenticate the identity of the 10 
publisher issuing publisher signature 110. Publisher digital 
certificate 122 is a cryptographic certificate that conforms, 
for example, to a standard X.509 certificate format with 
version 3 extensions, as promulgated in The Directory- 
Authentication Framework, CCITT (Consultation 
Committee, International Telephone and Telegraph) Inter- 
national Telecommunications Union, Geneva, 1989. 

In one implementation, publisher digital certificate 122 
includes the software publisher's name 124, the public key 
126 corresponding to the private key used by the publisher 
to form publisher signature U0, an expiration date (or 
validity period) 128 of the certificate, a link or hyperlink 130 
to the certification agency's policy for granting certificates, 
and a link or hyperlink 132 to the certification agency's 
identifier (e.g., trademark). In addition, publisher digital 
certificate 122 can include a version indicator that identifies 
the certificate format, a serial number and name that identify 
the certification authority, an algorithm identifier that iden- 
tifies the algorithm used to sign the certificate, together with 
any necessary parameters, and a signed-data object or sig- 
nature by the certification authority or agency (e.g., accord- 
ing to the PKCS #7). Publisher digital certificate 122 is 
issued by a certification agency that typically is separate 
from the software publisher. Digital certificate 122 is 
encrypted with a private key corresponding to a widely 
known and readily available public key. In other 
implementations, for example, publisher digital certificate 
122 might not include software publisher's name 124, link 
130, or link 132. 

With reference to FIG. 5, a root public key 136 for 
decrypting digital certificate 122 is associated with a 
browser application 138 that implements calls for reading 
and decrypting publisher signature 110. As a result, root 
public key 136 is widely known and distributed and rela- 
tively insusceptible to malicious substitution with a spurious 
public key. It will be appreciated, however, that root public 
key 136 can be widely known and distributed in other 
manners, such as by incorporation into other software appli- 
cations or operating systems, posting on an open network 
like the Internet, or publication. 

FIG. 6 is a flow diagram representing a publisher signa- 
ture confirmation method 150 that is performed, for 
example, by or in response to a call by browser application 



8 



example, PKCS Wl version 15, promulgated by RSA Labo- 
ratories, Whenever a publisher signature is not included in 
the program file, decision block 154 proceeds to process 
block 156, and otherwise proceeds to process block 158. 

Process block 156 indicates that a dialog or notice is 
rendered notifying the user of the absence of a publisher 
signature in the program file 138. The dialog can be rendered 
by browser application 138, for example, and can include 
user queries as to whether to open or run executable file 102. 

Process block 158 indicates that publisher digital certifi- 
cate 122 is decrypted with a widely known public key, such 
as public key 136 associated with browser application 138. 

Decision block 160 represents an inquiry as to whether 
digital certificate 122 is properly decrypted with public key 
136 to provide the information (e.g., public key 126, etc.) in 
digital certificate 122 in predetermined formats. Decision 
block 160 proceeds to process block 162 whenever digital 
certificate 122 is not properly decrypted by public key 136, 
and otherwise proceeds to process block 164. 

Process block 162 indicates that a dialog or notice is 
rendered, for example, by browser application 138, notify- 
ing the user that the publisher signature 110 attached to the 
program file is invalid. Hie dialog can be rendered by 
25 browser application 138, for example, and can include user 
queries as to whether to open or run executable file 102. 

Process block 164 indicates that publisher signature 110 is 
decrypted with the publisher's public key 126 included in 
and retrieved from publisher digital certificate 122. 

Process block 166 indicates that a hash or cryptographic 
digest is computed for the executable file 102, but not 
publisher signature 110 or selected other file components, as 
described below in greater detail. The hash or cryptographic 
digest is computed according to the hash algorithm, such as 
MD 5 or SUA 1, that is used to determine the cryptographic 
digest 106 included in the publisher signature 110. 

Decision block 168 represents an inquiry as to whether 
the cryptographic digest computed at the recipient computer 
matches the hash or cryptographic digest 106 included in 
publisher signature U0. Decision block 168 proceeds to 
process block 170 whenever the user-computed hash 
matches the cryptographic digest 106 included in publisher 
signature U0, and otherwise returns to process block 162. 

Process block 170 indicates that the recipient computer 
selectively renders a dialog 180 (FIG. 7) confirming the 
certification of the received code or executable file. The 
rendering of the dialog is selective in that the recipient can 
prevent dialog 180 from being rendered, for example, for 
particular certification agencies or publishers selected by the 
recipient or user as being trusted software publishers. 

FIG. 7 illustrates an exemplary digital certificate dialog 
180 rendered on a display screen associated with the recipi- 
ent computer 20 in accordance with process block 170 of 
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138. Signature confiraaton met^ 150 provides a recipient 55 signature confirmation method 150. Dialog 180 provides a 
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of executable file 102 (FIG. 4) with simple and effective 
assurance of the authenticity and integrity of executable file 
102. 

Process block 152 indicates that a user receives an execut- 
able computer program file via an open network like the 
Internet 

Decision block 154 represents an inquiry as to whether 
the executable file includes a publisher signature HO. For 
example, browser application 138 searches the received 



user with a simple two-part identity confirmation of the 
publisher of executable file 102. More specifically, dialog 
180 identifies the executable file 102 as having been "pub- 
lished by Publisher under an Internet publishing license 
60 granted by Agency." This identification of the Publisher with 
confirmation by the Agency or certification Agency provides 
the user with simple and effective authentication. 

In contrast, conventional certification methods can result 
in extensive chains of certifications and signatures by parties 



* , ti- — — m >>atvmiTv, vuttjuaui wnuutuuiK aim signatures Oy panies 

executable file or its header (as described below in greater 65 that each must be known to and accepted by the user. In 

detail) for a publisher signature in the form of a crypto- accordance with this invention, the identity of the software 

graphic message of a conventional standard such as, for publisher is certified by the certification agency. The repu- 
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lalion of the certification agency, together with the notoriety promised in other ways. For example, a private key could be 
or fame of a public key associated with the certification compromised by lax security precautions that allow the 
authority, provide a secure affirmation of the identity of the private key l0 ^ stolen or blicl released or a 
software pubhster - Moreover, the certification agency can ^ a ^ valid ^ 

reasonably certify the identity of many publishers without 5 t ^ !i . ,- , , J . ™^ ^ ^ 

the unworkable burden, on the agency and the publishers, of pr ° teCt tbe pubhshed lts hcense ' 

confirming the integrity of each executable file signed by Meta-agency digital certificate 190 provides publisher 
each of the publishers. digital certificate 122 with one or more indirect links to root 

In addition to certifying the identity of the publisher by public key 136. With one meta-agency certificate ISM), root 
the name and reputation of the certification agency, dialog 10 public key 136 complements the private key for encoding or 
180 provides the recipient of the software with graphical encrypting the meta-agency certificate 190, which itself 
control buttons 182 to selectively elect whether to run the nolds me public key for the publisher digital certificate 122. 
software and links 184 to additional information about the more man one meta-agency certificate 190, root public 

software and the publishing licenses issued by the certifi- 15 ^ey complements the private key for encoding or 
cation agency. Links 184 allow a software recipient, before encrypting the highest level meta-agency certificate 190, 
deciding to run the received or downloaded code, to obtain which holds the public key for the next lower level certifi- 
additional information about the software and the policies or cate E* 00 meta-agency certificate 190 holds the public 
authority under which digital certificate 122 was granted to kev for a 06x1 lower meta-agency certificate 190, except that 
the publisher who signed the software. This additional 20 the lowest level certificate 190 holds the public key for the 
information could be particularly helpful if the certification publisher digital certificate 122. 

agency or the software are not well-known to the recipient. Dialog 180 (FIG. 7) provides the recipient with identify- 
Graphical control buttons 182 give the recipient the choice ing information about the publisher and the immediate 
of whether to run the software based upon the reputation and ^ certification agency. This two-level identification confirma- 
apparent credibility of the publisher and the certification fi°n is applied whether the certification agency immediately 
agency. An optional graphical control button 186 accesses granting publisher certificate 122 is linked directly or inch- 
links to additional information about the executable file, reedy by one or more meta-agency certificates to root public 
such as endorsements or reviews. The links to this additional key 136. By omitting information about any meta-agencies 
information would be included in publisher signature 110. 30 in dialog 180, a recipient is spared the burden of separately 
In one embodiment, tbe agency granting publisher digital confirming the validity of each of meta-agency digital 
certificate 122 holds the private key that directly comple- certificate, thereby simplifying the confirmation for the 
ments the root public key 136 associated with browser recipient. 

application 138. Alternatively, the agency granting publisher 35 FIG. 9 is a flow diagram of an agency certificate decoding 
digital certificate 122 could hold a private key that is method 200 that is performed in substitution for process 
indirectly linked to root public key 136 through private keys blocks 158 and 164 of confirmation method 150. (It will be 
for one or more digital certificates by which a chain of at appreciated that inquiry 160 of method 50 would be per- 
least one meta-agency grants the certification agency the formed for each certificate that is decoded or decrypted.) 
authority to grant the digital certificate 122. 40 Process block 202 indicates that a top level meta-agency 

FIG. 8 is a diagrammatic illustration of a meta-agency d^al certificate 190 is decrypted with a widely known 
digital certificate 190 by which a higher-level or meta- Public key, such as public key 136 associated with browser 
agency grants a certification agency authority to issue pub- application 138. 

lisher digital certificates 122. One or more meta-agency 45 Process block 204 indicates that a next lower level 
digital certificates 190 may be appended to or incorporated meta-agency digital certificate 190 is decrypted with a 
in publisher digital certificate 122 according to the manner public key from the higher level agency certificate, 
in which certificate 122 is linked to root public key 136. Decision block 206 represents an inquiry as to whether 
Meta-agency digital certificate 190 includes for the certifi- the current lower level meta-agency digital certificate 190 
cation agency information that is analogous to the publisher 50 includes a public key to another agency digital certificate, 
information in publisher digital certificate 180, such as the Decision block 206 returns to process block 204 whenever 
agency name 192 and its public key 194. In addition, the current lower level meta-agency digital certificate 190 
meta-agency digital certificate 190 includes an expiration includes a public key to another agency, and otherwise 
date 196 for the certification-granting authority of the cer- 55 proceeds to process block 208. 

tification agency and an indication 198 of the scope of the Process block 208 indicates that publisher digital certifi- 
certification-granting authority (e.g., whether the certifica- cate 122 is decrypted with a public key obtained from the 
tion authority can only grant publisher digital certificates or lowest level agency certificate 190. 

can also license other certification authorities). in ODe embodiment, publisher signature 110 is attached or 

Publisher license expiration date 128 (FIG. 4) and agency 60 appended to or embedded or incorporated in executable file 
license expiration date 196 (FIG. 8) provide respective 102 such that it forms a single signed file to simplify 
digital certificates 122 and 190 with enhanced security by transmission, improve the security afforded by publisher 
limiting the periods during which they are valid and there- signature 110, and to maintain the transparent operation of 
fore susceptible to attempted counterfeiting. Although it is ^ publisher signature 110 for the recipient. Asingle signed file 
computationally infeasible to compute a private key from a prevents publisher signature 110 from being dissociated 
public key, it is possible that a private key could be com- from its corresponding executable file 102 in transmission or 
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at the recipient's computer. It will be appreciated, however, graphic digest or hash that is determined for the code 

that publisher signature 110 could alternatively be transmit- received at the recipient's computer. In addition, other 

ted with executable file 102 as a separate file while achieving components of the executable file or code may be excluded 

benefits of the present invention. fro no the hash computed at the recipient's computer, as well 

A consequence of transmitting executable file 102 and 5 ^ ^ 0T *&nd hash of the file. As a result, the hash that is 

publisher signature 110 as a single signed file is that the computed can, if the executable file remains unchanged 

signed file received by the recipient differs from executable except for ^ addition of the source confirmation, match the 

file 102 upon which publisher signature 110 is based Step on S inal cryptographic digest for the file. In one 

166mpublishersignatureconfirmationmethodl50(nG 6) 10 ^soviet confirmation is positioned sub- 

* i a a * ■ . i_- , stantially at the end of the executable file but in other 

includes determining a cryptographic digest for the execut- , ... * . ' , , m ULUCr 

m ai in? a f . f; t * ™ , , implementations the source confirmation could be placed at 

ableme lOZAcryp^ other locatioQS m ^ ^ iDchlding at s^^y ^ 

signed file, including executable file 102 and publisher beginning of the file, 
signature 110, would not match the cryptographic digest 106 

of executable file 102 alone included in publisher signature 15 e J^^! aiU P ub ^« f ignature 110 is incor- 

iin tw »™k~*™ m * ♦ i, a *u c porated or embedded 10 executable file 102 formatted as an 

110. TUB ^ embodiment memdes therefore, a manner of archilecture . noQSpecific portable executable (PE) file 

mcorporatmg or embedding publisher signature 110 in (sometimes referred to as an image file), which is described 

executable file 102 such that the latter may be distinguished below with reference to a Common Object File Format 

for computing a cryptographic digest. 20 (COFF) file utilized by the Microsoft Windows NT operat- 

Many file formats, including executable file formats, have m & system. Although not limited to the Microsoft Windows 

file headers that include identifying and format information NT operating system, the description of PE or image files 

about the file. The information in and the manner of orga- sometimes refers thereto for purposes of explanation, 

nizing such headers is ^Wished by convention for each ^th types of files include file headers with fields that 

executable file f format. V^ e described with reference to 25 identi£y Mormatioa about me me ^ ^ ^ 

particular file formate, the following description of a first established at particular offsets from the ^ginning of the file 

embodiinentissu^^ or me segmem m ^ ^ ^ fe ^^Tf^ ofeets 

accommodation for the particulars of such other formats. are delineated in particular numbers of memory units, such 

Publisher digital certificate 122 and publisher signature as 8-bit bytes. Table 1 lists fields used in the headers of PE 

110 together form a keyed source confirmation with a secure 30 and COFF files. It will be appreciated, however, that other 

representation of the executable file. The source confinna- file formats could utilize similar header information. 



TABLE 1 



Offset Size Field 



Description 



c!2 



16 



18 



2 Machine 

2 Number of Sections 

4 Time/Date Stamp 

4 Pointer to Symbol Table 

4 Number of Symbols 

2 Optional Header Size 

2 Characteristics 



Number identifying type of target machine. 
See Table 2, "Machine Types," for more 
information. 

Number of sections; indicates size of the 
Section Table, which immediately follows 
the headers. 

Time and date the file was created. 
Offset, within the COFF file, of the symbol 
table. 

Number of entries in the symbol table. This 
data can be used in locating a string table, 
which immediately follows the symbol table. 
Size of the optional header, which is 
included for executable files but not object 
files. An object file should have a value of 0 
here. The format is described in the section 
"Optional Header." 

Flags indicating attributes of the file. See 
Table 3, "Characteristics," for specific flag 
values. 



tion is keyed in that it (or a portion of it) is encrypted with 
a key, or includes a key, or both. A source confirmation with 
publisher digital certificate 122 and the publisher signature 
110 as described is both encrypted with a key and includes 60 
a key. 

In one embodiment, the certification is referenced in a 
header of the executable file, the reference including a 
pointer to the keyed source confirmation and an indication of 
the size of the keyed source confirmation. The header 65 
reference functions to identify the location of the keyed 
source confirmation so that it is not included in the crypto- 



The Machine field at offset 0 may have one of the values 
set forth in Table 2 specifying the machine (CPU) type for 
which the file was created. An image file can be run only on 
the specified machine or a system emulating it The Char- 
acteristics field at offset 18 contains flags that indicate 
attributes of the object or image file, as set forth in Table 3. 
The optional header is described in greater detail below. The 
remaining header fields listed in Table 1 as Number of 
Sections, Time/Date Stamp, Pointer to Symbol Table, Num- 
ber of Symbols, Number of Sections relate to file size, dale 
and organization details and are self-explanatory. 



V 
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TABLE 2 



Constant 



VWuc DcscriptioD 



tMAGE_FILJE_MACHINE__UNKNOWN 

LMAGE_FtLE_MACHINE_I386 

IMAGE_FILE_MACHINE_R4000 
IMAGE_FILE_MACHINE_JUJ > HA 
IMAGE_JTLE_MACHINE_M68K 
IMAG E_FILE_MACinNE_POWERPC 
IMAGE_F1LE_MACHINE_PARISC 



0x0 Contents assnmcd to be applicable to 

any machine type. 
0 x 14c Intel 386 or later, and compatible 

processors. 
0 x 166 MIPS ® little endiaiL 
0 x 184 Alpha AXP ™. 
0 x 268 Motorola 68000 series. 
0 x 1P0 Power PC, little endian. 
0 x 290 PA RISC. 



TABLE 3 



Flag 

IMAGE_FILE_RELOCS_SrRlPPED 



Ox 0001 



IMAGE_J?TLE_JEXECIJTABLE_aMAGE 0 x 0002 



IMAGE_FIUE_LINE_NUMS_STRIPPED 0 x 0004 

IA^GE_FILE_lJOCAU_SYMS_5rRIPPED 0x0008 

[MAGE_FILE_MINIMAL_OBJECr 0 x 0010 

IMAGE_FLLE_UPDATE_OBJECT 0 x 0020 

IMAGE_FTLE_J 6BiT_MACHINE 0 x 0040 

rMAGE_Fn j^_BYTES_REVERSED _LO 0 x 0080 

IMAGE_iTLE_32BrT__MACHlNE 0 x 0100 

rMAGE_FILE_DEBGUG_STRIPPED 0 x 0200 

IMAGE_FTLE_PATCH 0 x 0400 

IMAGE__FILE_SYSTEM 0 x 1000 

IMAGE_FILE_JDLL 0 x 2000 



IMAGE_Fn^_BYTES_REVERSED _jn 0 x 8000 



Description 

Image only. Indicates that the file does not 
contain base relocations and must therefore 
be loaded at its preferred base address. If the 
base address is not available, the loader 
reports an error, operating systems running 
on top of MS-DOS (Win32s ™) are generally 
not able to use the preferred base address 
and so cannot run these images. However, 
beginning with version 4.0, Windows will use 
an application's referred base address. 
Image only. Indicates that the image file is 
valid and can be run. If this flag is not set, it 
generally indicates a linker error. 
COFF line numbers have been removed. 
COFF symbol table entries for local symbols 
have been removed. 
Reserved for future use. 
Reserved for future use. 
Use of this flag is reserved for future use. 
little endian: LSB precedes MSB in memory. 
Machine based on 32-bit-word architecture. 
Debugging information removed from image file. 
Reserved for future use. 
The image file is a system file, not a user 



The image file is a dynamic-link library (DLL). 
Such files arc considered executable files for 
almost all purposes, although they cannot be 
directly run. 

Big endian: MSB precedes LSB in memory. 



The optional header is optional in that it is included in 
image (PE) files but not object files (COFF object modules). 
As a result, this header is also referred to as the PE Header. 
An object file may have an optional header, but generally 
this header has no function in an object file except to 
increase size. Table 4 lists the three major parts of the 
Optional Header. 

TABLE 4 

Offset Size Header part Description 



28 



28 Standard 

fields 
68 NT-specific 

fields 



These arc defined for all implementations 

Of COFF, f'nrfnHfng UNIX ®. 

These inemde additional fields to support 
specific features of Windows NT (for 
example, subsystem). 



50 



55 



60 



65 



TABLE 4-continued 



Offset Size Header part Description 



96 128 Data These fields are address/size pairs for 

directories special tables, round in the image file and 
used by the operating system (for 
example, Import Table and Export Table. 



Table 5 lists the first nine fields of the Optional Header, 
which are standard fields that are defined for every imple- 
mentation of COFF. These fields contain general informa- 
tion useful for loading and ninning an executable file. Table 
6 lists the next twenty-one fields, which are an extension to 
the COFF Optional Header format and contain additional 
information needed by the linker and loader in Windows NT. 
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TABLE 5 



Offset Size Field Description 



0 2 Magic Unsigned integer identifying the state of the 

image file. The most common number is 
0413 octal (0 x 10B), identifying it as a 
normal executable file. 0407 (Ox 107) 
identifies a ROM image. 

2 1 LMajor Linker major version number. 

3 1 LMinor Linker minor version number. 

4 4 Code Size Size of the code (text) section, or the sum 

of all code sections if there are multiple 
sections. 

8 4 Initialized Data Size Size of the inih'»liy*H data section, or the 

sum of all such sections if there are multiple 
data sections. 

12 4 Uninitialized Data Size Size of the uninitialized data section (BSS), 

or the sum of all such sections if there are 
multiple BSS sections. 

16 4 Entry Point RVA Address of entry point, relative to image 
base, when executable file is loaded into 
memory. For program images, this is the 
starting address. For device drivers, this is 
the address of the initialization function. 

20 4 Base Of Code Address, relative to image base, of 

beginning of code section, when loaded into 
memory. 

24 4 Base Of Data Address, relative to image base, of 

beginning of data section, when loaded into 
memory. 



TABLE 6 



Offeet Size Field 



Description 



28 4 Image Base 

32 4 Section Alignment 



36 



68 



4 File Alignment 



40 


2 


OS Major 


42 


2 


OS Minor 


44 


2 


User Major 


46 


2 


User Minor 


48 


2 


SubSys Major 


50 


2 


SubSys Minor 


52 


4 


Reserved 


56 


4 


Image Size 


60 


4 


Header Size 


64 


4 


File Checksum 



2 Subsystem 



70 2 DLL Flags 

72 4 Stack Reserve Size 



76 



4 Stock Qwnmit Size 



Preferred address of first byte of image 
when loaded into memory; must be a 
multiple of 64 K. 

Alignment (in bytes) of sections when 
loaded into memory. Must greater or equal 
to File Alignment. Default is the page size 
for the architecture. 

Alignment factor (in bytes) used to «Kgn 
pages in image file. The value should be a 
power of 2 between 512 and 64K inclusive. 
Major version number of required OS. 
Minor version number of required OS. 
Major version number of image. 
Minor version number of image. 
Major version number of subsystem. 
Minor version number of subsystem. 

Size, in bytes, of image, mchiding all 
headers; must be a multiple of Section 
Alignment. 

Combined size of MS-DOS Header, PE 

Header, and Object Table. 

Image file checksum. The algorithm for 

computing is incorporated into 

1MAGHELP.DLL. The following are checked 

for validation at load time: all drivers, any 

DLL loaded at boot time, and any DLL that 

ends up in the server. 

Subsystem required to run this image. See 

"Windows NT Subsystem'* below for more 

infrcTTTTfltfftfl 

Obsolete. 

Size of stack to reserve. Only the Stack 
Commit Size is coinmitted; the rest is m»A^ 
available one page at a time, 
until reserve size is reached. 
Size of stack to commit 
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TABLE 6-continued 



Ofiset 


Size 


Field 


Description 


80 


4 


Heap Reserve Size 


Size of local heap space to reserve. Only 








the Heap Commit Size is committed; the 








rest is made available one page at a time, 








until reserve size is reached. 


84 


4 


Heap Commit Size 


Size of local heap space to commit. 


88 


4 


Loader Flags 


Obsolete. 


92 


4 


Number of Data 


Number of data-dictionary entries in the 






Directories 


remainder of the Optional Header. Each 








describes a location and size. 



Table 7 lists values defined for the Subsystem field of the 15 The certificate table field at offset 128 references the 

Optional Header. They determine what, if any, operating address and size of an attribute certificate table that contains 

system (e.g., Windows NT) subsystem is required to run the one or more fixed length table entries. Each entry of this 

image file. table identifies the beginning location and length of a 



TABLE 7 



Constant 



\&hie Description 



lMAGE_SUBSYSTEM_UNKNOWN □ 

rMAGE_SUBSYSTEM_NATrVE 1 

[M AGE_S UBSYSTEM__WTNDO WS_GUI 2 

IMAGE_SUBSYSTEM_WTNDOWS_CUl 3 

IMAGE_S UBSYSTEM_POSDC_Cm y 



Unknown subsystem. 

Used for device drivers and native Windows NT 
processes. 

Image runs in the Windows ™ graphical user 
interface (GUI) subsystem. 
Image runs in the Windows character subsystem. 
Image runs in the Posix character subsystem. 



Each data directory gives the address and size of a table 
or string used by Windows NT These are loaded into 
memory so that they can be used by the system at run time. 
A data directory is an eight-byte field that has the following 
declaration: 

typedef stnict_IMAGE_DATA_DIRECTORY { 
DWORD RVA; 
DWORD Size; 

} IMAGE J>ATA__J>IRECTORY, *PIMAGE_DATA^_ 
DIRECTORY; 

The first field, RVA, is the relative virtual address of the 
table. The RVA is the address of the table, when loaded, 
relative to the base address of the image. 
The second field gives the size in bytes. Table 8 lists the data 
directories, which form the last part of the Optional Header. 



corresponding signature 110 or certificate 122. There is one 
Certificate Table entry for each certificate stored in this 
section. The number of entries in the certificate table is equal 
to the size of the certificate table (found in offset 132) 
divided by the size of an entry in the certificate table (8). The 
size of the certificate table includes the table entries, not the 
actual certificates, which are pointed to by the table entries. 
Table 9 shows the format of each table entry. 

TABLE 9 

Offset Size Field Description 

0 4 Certificate Data File pointer to the certificate data. 

This will always point to an address 



40 



TABLE 8 



Offset 


Size 


Field 


Description 


96 


8 


Export Table 


Export Table address and size. 


104 


8 


Import Table 


Import Table address and size 


112 


8 


Resource Table 


Resource Table address and size. 


120 


8 


Exception Tabic 


Exception Table address and size. 


128 


8 


Certificate Table 


Attribute Certificate Table address and size. 


136 


8 


Base Relocation Table 


Base Relocation Table address and size. 


144 


8 


Debug 


Debug data starting address wnd size. 


152 


8 


Copyright 


Copyright string address and length. 


160 


8 


Global Ptr 


Relative virtual address of the global 








pointer register. Size member of this 








structure is set to 0. 


168 


8 


TLS Table 


Thread Local Storage (TLS) Table address 








and size. 


176 


8 


Load Config Table 


Load Configuration Table address and size. 


184 


40 


Reserved 





19 

TABLE 9-continued 
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Of&et Size Field 



Description 



that is octaword aligned (Le., is a 
multiple of 8 bytes and so the low- 
order 3 bits arc zero). 
0 4 Size of Certificate Unsigaed integer identifying the size 

(La bytes) of the certificate. 

In one embodiment, an attribute certificate table is added 
at the end of the image, with only a debug section following 
(if a debug section is present). Certificates start on an 
octaword boundary. If a certificate is not an even number of 
octawords long, it is zero padded to the next octaword 
boundary. However, the length of the certificate does not 
include this padding and so any certificate navigation soft- 
ware must be sure to round up to the next octaword to locate 
another certificate. Each certificate is represented by a single 
Certificate Table entry. The certificate starting location and 
length is specified by an entry in the Certificate Table. 

Several certificates or attribute certificates are expected to 
be used to verify the integrity of an image, image file, or PE 
file. The certificates ensure that a particular image file, or 



10 



15 



20 



part of that image file, has not been altered in any way from 

its original fornt and typically include cryptographic digests 25 ^7^2^ "^f^f n Uie resources are cnUcal 
that are sometimes called message digests. 10 311 image me „ or ^cation, Respite the overhead of 



a message digest, the following information is excluded 
from that calculation: the debug entry of the data directory 
in with optional header and the debug section. 

The file Checksum field of the Windows NT-specific 
fields of the optional header should be omitted. This check- 
sum field includes the entire file (including any attribute 
certificates included in the file) and would likely be changed 
by insertion of a certificate. 

There are several fields that are either unused or obsolete. 
The values of these fields are undefined and can change after 
the message digest is calculated. These fields include: 
reserved field of the optional header Windows NT-specific 
fields (offset 52), the obsolete DLL flags field of the optional 
header Windows NT-specific fields, the obsolete loader flags 
field of the optional header Windows NT-specific fields, and 
the reserved entries of the data directory in the object header. 

Resources are commonly used to house localizable strings 
and are sometimes used to bouse raw data or, on rare 
occasions, even executable code. Under different 
circumstances, it may be desirable or undesirable to include 
resources in the message digest. Resources may be omitted 
from the message digest to allow localization without the 
generation of new certificates. It may be desirable to include 
resources in the message digest if the resources are critical 
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Message digests are similar to a file checksum in that they 
produce a value that relates to the integrity of a file. A 
checksum is produced by a simple algorithm and its use is 
primarily to detect memory failures. That is, it is used to 
detect whether the values stored in memory have become 
corrupted. A message digest is similar to a checksum in that 
it will also detect file corruptions. However, unlike most 
checksum algorithms, a message digest also has the property 
that it is very difficult to modify a file such that it will have 
the same message digest as its original (unmodified) form. 
That is, a checksum is intended to detect simple memory 
failures leading to corruption, but a message digest can 
detect intentional modifications to a file, such as those 
introduced by viruses, hackers, or Trojan Horse programs. 

It is not desirable to include all image file data in the 
calculation of a message digest In some cases it simply 
presents undesirable characteristics (like the file is no longer 
localizable without regenerating certificates) and in other 
cases it is simply infeasible. For example, it is not possible 
to include all information within an image file in a message 
digest, then insert a certificate containing that message 
digest in the file, and later be able to generate an identical 
message digest by including all image file data in the 
calculation again (since the file now contains a certificate 
that wasn't originally there). 

The following fields should not or can not be included in 
a message digest. Attribute or publisher certificates are 
omitted from the calculation of a message digest that resides 
within the certificate. The overall integrity of the image file 55 
is not affected by adding or removing certificates. To exclude 
attribute certificate information from the message digest 
calculation, the following information is excluded from that 
calculation: the certificate table field of the optional header 
data directories and the certificate table and corresponding 60 
certificates pointed to by the certificate table field. 

Debug information may be considered advisory to debug- 
gers and does not affect the integrity of the actual executable 
program. The debug information can be removed from an 
image file without affecting its functionality. (Deletion of 65 
debug information is sometimes used to reduce the size of 
distributed image files.) To exclude debug information from 



generating a certificate for each localized copy of the image. 
If resources are omitted from the message digest, the fol- 
lowing information should not be included in the message 
digest calculation: resource table entry of the optional 
30 header data directory and the jsrc section. 

In a second embodiment, publisher signature 110 is incor- 
porated or embedded in executable file 102 formatted as a 
Java class file, as defined in The Java Virtual Machine 
Specification, by Sun Microsystems Computer Corporation 
of Mountain View, Calif. This type of file also includes a file 
header with fields that identify selected information about 
the file. A Java class file consists of a stream of 8-bit bytes. 
All 16-bit and 32-bit quantities are constructed by reading in 
two or four 8-bit bytes, respectively. The bytes are joined 
together in network (big-endian) order, where the high bytes 
come first. 

The class file format is described here using a structure 
notation. Successive fields in the structure appear in the 
external representation without padding or alignment Vari- 
able size arrays, often of variable sized elements are called 
tables and are commonplace in these structures. The types 
ul, u2, and u4 mean respective unsigned one-, two-, or 
four-byte quantities. The top-level structure of a class file is 
represented as: 
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ClassFflc 
{ 

u4 
u2 
u2 
u2 
cp_Jnfo 
u2 
o2 
u2 
u2 
o2 
u2 

field_info 
u2 

method _Jnfo 
u2 



minor version; 

niajoi_version; 

co nstanl poo l_count; 

constant pool[cnfi<t tnnt ponlraiint - 



It 



this class; 

super_dass; 

Late rfaces__count; 

interface4uiterfa£«s_couati 

fields_count 

fields(fielcls_couritJ 

methods_counl; 

mcthods(melhods count J 

attributes count; 
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If the message digest algorithm is known, the design 
-continued presented here allows for a one-pass computation of the hash 

. value except in a two cases. In the first case, there are two 

attribute attribmcslattnbmc.countt or more constant pool entries with type CONSTANT_Utf8 

- _ 5 va iue "_digftal^signature_ , \ When hashing the bytes 

of the constant_j>ool, performance-conscious implementa- 
tions may assume that the first such entry will be the last and 
only entry, and backtrack and recompute the hash of the 

- ; — — constant pool should this prove later in the pool to be in 

GencncAtoQmtc.info ^ error This case should happen only if the string constant 

□2 attributc_oamc- "_digital_signature_" is in use by the class code itself, and 

o4 attributc_icngth; * encoded in the constant pool as a CONSTANT_Utf8 

ui info[attributc_jcngtht instead of the alternate CONSTANT_Unicode representa- 

r tion. This can be avoided if compiler writers emit the string 

" ~ in the alternate CONSTANT_Unicode representation 

Attributes have the following semantics. The attribute_ instead of CONSTANT_Utf8 when the constant value 
name is a 16-bit index into the class constant pool and the digjtal_signature_" is used by class code, 

value of conslant__pooI[attribute_name] is a CONSTANT^ 1° second case, there are two or more attributes with 
Utf8 string giving the name of the attribute. The field lne name "_digital_signature_ w . When hashing the 
attribute_length indicates the length of the subsequent attributes, performance-conscious implementations may 
information in bytes. This length does not include the six 20 assume that the first such attribute will be the last and only 
bytes of the attribute_name and attributejength. such attribute, and backtrack and recompute the hash of the 

In accordance with this embodiment, a new attribute type attributes should this prove later in the list to be in error It 
is defined for containing a "signature block", a publisher is expected that this case is unlikely to happen in practice 
signature 110 of the classfile. The name of this attribute is To facilitate one-pass processing of the verification of the 
digital^ignature The information in this attribute is 25 signatures of . cIass MtSy a preferential hash algorithm (e.g., 
the signature block of the file, a PKCS #7 SignedData. To MD5) may be used to sign .class files. PerformLt 

hi l T ^ conscious implementations Zy wish to assume £1 

name is considered the signature block. The constant pool iU „ . r tU A1 * t , 4 . , , ' , 

entry corresponding to theTignature block attribute, them Sit .hffik SSf ^^'^T^^ 
that contains the string «_digital_signature_", is the last 30 u ^ ^ \ detenmned ( when decoding 

constant pool entry of type CONSTANT_Utf8 and this , ° I f CS .* 7 Signed-Data) that a different or additional 

value.And,thesignatareblockattributeistheonlyreference 15 r ^ ,mred J° Ul. - *? 

in the file to this constant pool entry. algorithms used are indicated inside the PKCS #7 Signed- 

The sequence of bytes to be hashed or for which the Way accocdiD & l ° definition of that 

message digest is calculated is the sequential contents of the 35 a VP 6 - ... 

class file as defined by the above ClassFfle structure „. A a k ?L ^ W ^/P™ 31 of a 

(specifically, therefore, with integers, etc., in big endian fignedDaU as defined by PKCS #7: Cryptographic Message 

order), with the following omissions from the hash: (1) the d ^dard, ^enhancements for signing Java class 

conslanl_pool_count, (2) the attribute_count, (3) the last *"* 5^ specification are summarized for 

constant pool entry, if any, with type CONSTANT UtBand 40 e^aLon of the extensions. The SignedData format, like 

value «_digital_j5ignature (4) the entirety of the last f<£ , !^ standard data formats, are defined using the 

attribute,^, wiu^enaie"%.al_sign y ature»,and u acmmS Syntax Notation as defined by the ITU-T. 

(5) any "extra" bytes which may be in the file beyond the abs^t syntax specification specifies a stream 

logicalendofthe-classfileasdefinedbytheaboveClassFUe b > * P ^ C * U " ASNlJ"Basic Encoding 

structure. The first four omissions make the bash process 45 ££L" D^tmguished EncoAng Rules" as appropriate, 

tovariantimdermeprescnceorabsenceofadigitalsignature ¥^ " fTt&FZS? , 1 

mtheclassme.TBeVissimplyaclarmcationofptteotial %^°V L^" 1 ^ T ™~ ^ 

ambiguity. ASN.l for a SignedData is specified by PKCS #7 as: 

To maintain the invariance of the hash, points 3) and 4) 

omit from the hash the information that the signing process 50 

adds to the file. Some variation on 1) and 2) is also needed, SignedData : sequence { 

for the same reasons. Ad alternate design for 1) and 2) might wnaon \femon, 

be to include the two counts in the hash and to decrement <KgesiAlgprithms DigpstAlgprithmldentifiera 

them each by one in thecase where the class file already — ° SS££r ^c.n^^^ 

contains a signature, fins alternate design functions 55 optional, 

correctly, but necessitates that when hashing information at ^ [l] IMPLICIT CeitificatcRcvocotiDnLists OPTIONAL, 

the start of the file one knows whether the file contains a agnertnfos Signerlnfos } 

signature or not, which can only be determined by looking " 

at the attributes towards the end of the file. Omitting the two The contentlnfo field contains the content data to be 
counts facilitates a one-pass computation of the hash value 60 signed. The zero or more signerlnfos contain the signature or 
and does not create a potential security lapse. signatures on that data. The set of certificates in Extended- 
Each constant pool entry and attribute is non-zero in size, CertificatesAndCertificates are intended to be sufficient to 
and the nature of message-digest algorithms is that it is contain chains from a recognized "root" or "top-level cer- 
computationally infeasible to find any two distinct messages tification authority" to all of the signers in the signerlnfos 
of any length that have the same message digest PKCS #7 65 field, though this is not required. There may be fewer or 
SignedDatas employ a similar omission of length bytes with more certificates than are necessary. Contentlnfo is defined 
no concern as to a potential attack. by PKCS #7 as: 
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CONTENTINFO CLASS { 
AType, 

&ld OBJECT IDENTIFIER UNIQUE 

} 

WITH SYNTAX { 

WITH SYNTAX &Typc 

ID &id 

} 

Contentlnfo ::= SEQUENCE { 
contcntTypc CONTENTINFD.&id, 

content [0] EXPLICIT CONTENTINFO. &Type OPTIONAL 



Hie design presented in PKCS #7 has the actual content 
contained physically inside the Contentlnfo. To refer in the 
Contentlnfo to an external data source, a new Contentlnfo 
type is defined called IndirectDataContent. An IndirectData- 
Content contains: 1) an indication of the kind of data to be 
hashed. This is an object identifier; thus, new kinds of 
indirect data can be independently created. 2) Optionally, an 
indication of the actual data to be hashed. This is specified 
in a syntax governed by the object identifier. Commonly this 



indicated data, along with an indication of the digest algo- 
rithm used. This digest/digest algorithm pair is then itself 
digested and signed as part of the signing process of the 
SignedData per PKCS #7, thus, indirectly, associating a 
digital signature with the indicated data. 

The definition of IndirectDataContent and related struc- 
tures is as follows: 
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indirectDataContent CX)NTENTINFO ::= { 
WITH SYNTAX IndirectDataContent 
ID id-indirectdata 
} 

IndirectDataContent ::= SEQUENCE { 
data AtttibuteTypeAndOptionalVahie, 
messageDigest Digestlnfo — Digestlnfo defined in PKCS #1 

AttributeTypcAndOptionalVahie ::- SEQUENCE { 
type ATTRIBUTE. & id, 

value ATTRTOUTE.&Type ({. . -}{@type}) OPTIONAL 

id-indirectdata OBJECT IDENTIFIER ::- (value to be supplied) 
javaClassFileSourceTvpe ATTRIBUTE ::- { 

WITH SYNTAX JavaClassFileData 

ID id-indirectdata-javaClassFile 

id-indirectdata-javaclassFfled OBJECT IDENTIFIER (value to be supplied) 
JavaClassfiJeData Link 
Link ::- CHOICE { 

uil [0] IMPLICIT UnifonnResourceLocator, 

moniker [1] IMPLICIT SerializedMoniker, 

file [2] IMPUCrr F0eName 

} 

UnifonnResourceLocator ::- IA5String 
FUeNamc ::= DcmiString 
SeriaiizedMoniker ::» SerializedObject 

— A * moniker * is a term from OLE. It is a 'persistentablc, intelligent 

— name*. See the OLE Component Object Model specification for more info 
SerializedObject SEQUENCE { 

ctassid Uuid, 

serializedData OCTET STRING — format determined by class id 
} 

Uuid ::- OCTET STRING (STZE(16„16)) — an OSF UUID 
Dcmistring ::- CHOICE { 

Unicode [0] IMPLICIT BMPString, 

ascii [1] IMPLICIT IA5 String 



is a file name, a URL, etc., along with any additional 
parameters needed that indicate which specific sub-part of 
the indicated data is involved. If this indication is absent, 
then the actual data to be hashed is located implicitly in an 
object-identifier-specific means, such as the file in which the 
todirectDataContent is physically located (For Java class 65 
files, this indication is typically omitted, indicating that the 
indicated data is the containing class file.) 3) A digest of the 



FIG. 10 is a flow diagram of a digital certificate revoca- 
tion method 220 that minimizes or eliminates the potential 
for harm that can be caused by compromised digital certifi- 
cates. Method 220 would be performed in the interim 
between determining that the digital certificate is valid in 
accordance with decision block 168 and the rendering of the 
digital certificate dialog in accordance with process block 
170 of method 150 (FIG. 6). 
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Process block 222 indicates that a listing of revoked 
digital certificates is obtained by or downloaded to the user's 
or recipient's receiving computer. The listing may be 
obtained or updated on a regularly scheduled basis (e.g., 
daily) so it is substantially current whenever the user down- 
loads executable file 152. It will be appreciated that the 
listing will include only digital certificates that have been 
revoked and have not yet expired. As a result, publisher 
license expiration date 128 (FIG. 4) and agency license 
expiration date 196 (FIG. 8) provide the additional benefit of 
preventing the revocation listing from growing indefinitely 
and thereby becoming unworkably large. 

To further reduce the size of the revocation listing so it 
can be downloaded frequently with minimal network band- 
width and storage requirements, a secure hash (e.g., MD5) 
of the listing can be delivered. This prevents casual inspec- 
tion of the revoked digital certificates, which increases 
privacy and security for the revocation listing. There is a risk 
of false revocation due to hash collisions, but the probability 
of this is extraordinarily minuscule for hash functions such 
as MD5. The revocation listing may be in the form of the 
following database table, except that the actual licenses 
being revoked would not be transmitted to users. 

TABLE 10 
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Column Name Type 



Description 



SequenceNumber DWORD 



RevokeUnrevoke 
Fir Ftp Date 

Hashli certs 
license 



BOOLEAN 
DATE 

BYTE{128] 
BLOB 



A counter. Each revoke or unrevoke 
operation is given a forever-unique tag. 
True if revoking, false if unrevoking 
The expiration date of the license 
(cached from the license itself) 
The MD5 hash of the license 
The actual license being revoked 



license that indicates which licenses or digital certificates 
this agency is allowed to revoke or unrevoke. Each meta- 
agency has the right to grant revocation rights to child 
agencies that it directly licenses. As a result, the right to 
populate this second table is controlled by other entries in 
the same table. 

In one implementation, a software publishing trust pro- 
vider module handles specified actions under a 
Win VerifyTmstO function included in the Win32 application 
programming interface (API) set from Microsoft Corpora- 
tion and verifies the tnistability of software components by 
interpreting local system rules and analyzing cryptographic 
material associated with those software components. The 
caller (i.e., application calling the Win VerifyTmstO 
function) specifies the trust provider that evaluates the 
subject according to the action requested. 

The software publishing trust provider module allows 
users to install any software desired on their systems, but 
requires user interaction prior to installation of software not 
determined to be trustable by the available cryptographic 
material. The trust provider makes use of XS09 version 3 
certificates and PKCS #7 digital signature structures, as 
described above. 

The software publishing trust provider module is called 
by using the Win32 API Win VerifyTmstO function, which 
has the following prototype: 
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Decision block 224 indicates that an inquiry is made as to 
whether the digital certificate is included in a listing of 
revoked digital certificates. Decision block 224 proceeds to 
process block 226 whenever the digital certificate is 
included in the revocation listing and otherwise proceeds to 
process block 170 (FIG. 6). 40 

Process block 226 indicates that a dialog is rendered 
indicating that the digital certificate has been revoked and 
asking the user whether or not to run the program file. 

Digital certificates would typically be revoked by the 
agency or meta-agency that issued them. The database of 45 
revoked digital certificates would also include a table by 
which different agencies and meta-agencies post and admin- 
ister the revocation of digital certificates. 



HRESULT 




WINAPI 




Win\fcrifyTrust( 




HWND 


hwnd, 


DWORD 


dwTrustProvider, 


DWORD 


dw Actio nlD, 


LPVOfD 


ActionOata, 


* 





TABLE 11 



Column Name Description 
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Accountlnfo The database account under which this licensee ts 

allowed to exercise his revocation & granting rights- 
License The license of an agency or mcta agency. 
IsMetaAgency Whether the agency is a meta agency or not. Cached 
from the license itself. 



The indication of whether the revoking agency is a meta- 
agency is optional. Each agency or meta-agency has the 60 
right to revoke licenses that it directly issued. That is, it can 
revoke licenses for which its license is the penultimate link 
in the certification chain. 

The function of Table 11 is to confirm whether an instruc- 
tion to revoke or unrevoke a license is authorized. The 65 
database looks up the agency's credentials in the 
Accountlnfo column, obtaining from that the corresponding 



The Software Publishing trust provider is identified by the 
WINBASE.H constant: 

#define WLN_TRUST_SOFTWARE_PUBUSHER 
Calls where this value is passed for the dwTrustProvider 
parameter are bandied by the Software Publishing trust 
provider. The trust provider supports two actions (passed in 
the dwActionID parameter), defined as: 

^define WIN_SPUB_ACTION_TRUSTED_ 
PUBLISHER 

tfdefine WIN_SPUB__ACTION_PUBLISHED_ 
SOFTWARE 

In one implementation, the software publishing trust pro- 
vider is also the system default provider for these actions. 
Therefore, if the caller specifies in the dwTrustProvider the 
constant: 

^define WIN__TRUST_PROVIDER_UNKNOWN and 
the action is either of those defined above, the call will 
also be handled by this trust provider. This is the calling 
method that most applications will employ, because it 
allows later system configuration options, which permit 
system or network administrators to assign various 
more-or-less stringent trust providers to handling these 
actions, without requiring modification to the applica- 
tions. 

The parameters for the WinVerifyTrustO function are: 
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Parameter 



Description 



hwnd Normally, every attempt is made to mnVr trust decisions 

without the aid of an interactive user. However, situations may 
arise wbere trust can be more accurately determined with user 
approval or decision. This parameter is used to indicate 
whether an interactive user is available to assist in any trust 
decisions. If this value is passed as 

IWALID_JIANDLE_VALUE, then no user interface (UI) will be 
presented and some default decision will be r m*<fo without a 
user's assistance. If this value is set to any other value, then it 
is assumed that there is an interactive user available. If the 
value is zero (0), then the caller's desktop will be used for any 
UI. Any other value is assumed to be the HWND of a calling 
user's window. 

DwTrust Provider Specifics which trust provider ts to be utilized to answer the 
question of trust. This value establishes what the remaining 
parameter values mean. V&lucs defined for dwTrustProvidcr 



define WIN_TRUST^ROVTDER_UNKNOWN 0x000000 
Wefine WIN_TRUST_SOFTWARR__PUBLISFIER QxOOOOO 

dwActionlD Specifics what the trust provider is being asked to verify. Each 
trust provider supplies its own set of trust actions. 

Actio oData This parameter is used to pass information required by the trust 

provider, including data about the level of trust required or 
context for the trust decision and, where applicable, information 
about the subject being verified. The meaning and format of the 
information passed via this parameter is dependent upon the 
action specified in the dw Actio nlD parameter. 



This service dispatches the specified ActionData informa- 
tion to the selected trust provider for trust evaluation. If the 
trust provider specified is WIN__TRUST_PROVIDER_ 
UNKNOWN, then the system will select an appropriate trust 
provider for the action specified by the dwActionlD 
parameter, or return the error TRUST _E_PROVTDER_ 
UNKNOWN if no trust provider that supports that action is 
installed. 



in the ActionData parameter is trusted for the specified 
action. The function may return one of the standard return 
values defined below, or a trust provider specific value. 

If a value other than STATUS_SUCCESS is returned, 
then the subject is either not trusted, or is trusted with some 
caveats. These caveats, if any, are specified by trust provider 
specific return codes and would be documented with each 
trust provider. The standard error return codes are: 



Status Code 

TRUST_E_SUBJECT __NOT_TRUSTED 

TRUST_E_PROVIDER_UNKNOWN 

TRUST_E_ACnON_UNKNOWN 

TRUST__E^UBJECT_FORAL_UNKNOWN 



Meaning 

The subject is not trusted for the specified action. 
Most trust providers will return a more detailed 
error code than this when trust is not provided, 
but in some cases this undescriptive value may 
be returned. 

The specified trust provider is not known on this 
system. 

The trust verification action specified is not 
supported by the specified trust provider. 
The form specified for the subject is not one 
supported or known by the specified trust 
provider. 



The definition of the ACTIONDATA structure may be Many trust providers will require only minimal context 

common among trust providers or a trust provider may 60 data for trust evaluation. They derive most of the informa- 

define specific ACTIONDATA structures it supports. Com- tion needed for trust decisions directly from a subject The 

mon ACTIONDATA structures are described below. subject is a data stream which is to be validated by the 

WinVerifyTrustO call. Some ACTIONDATA structures are 

This function returns an HRESULT indicating the results 65 used by several trust providers and they are described 

of the trust inquiry. STATUS_SUCCESS (or ERROR_ independent of them. The following ACTIONDATA data 

SUCCESS) indicates that the subject information provided structures are defined: 
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typcdcf LPVOID WIN_TRUST_SUBJECr 

typcdcf strod_WIN_TR UST_^CTDAIA^CONTEXT_ WITH_S UBJECT { 

HANDLE bOienflbfacn; 

DWORD dwStibjedType; 

WIN_TRUST_SUBJECT Subject; 
} WIN_TRUST^CroAD^(X>NTEXT_Wmi_SUBJECT, 

• WIN_TRUST_ACTDAIA_CONTEXT_WlTH_SUBJECr 
typcdcf stnict_WIN_TRUST^CroAlA_SUBJECr__ONLY { 

DWORD dwSubjecfrypc; 
WIN_TRUST_SUBJECT Subject; 
} WIN_TRUST_ACTDAlA__SUBIECr_ONLY, 

• lPWIN_TRUST^CroATA_SUBJECT_ONLY 



Within these data structures, the format of the subject data When the WIN__SPUB_ACTION_PUBUSHED_ 

is specified by the value of the dwSubjectType field. The SOFTWARE action is invoked, the subject is inspected to 

hClientToken parameter in the WIN_TRUST_ see if it contains a PKCS Wl signed data structure. If it does, 

ACroATA^CONTEXT_WITH_SUBJECT structure is the structure is expected to contain a chain of X.509 cer- 

used to pass a handle to the security context of the calling ^ tificates. In this development release, a root certificate must 

application. A trust provider may use the security context ^ present that is a self-signed certificate containing a root 

when evaluating trust of the subject. public key and is signed by the root private key. 

Subject types describe formats of the data stream being Additionally, a certificate must be present that is signed by 

validated by a WinVerifyTrustO call. The subject types are the 1001 P rivate key and identifies a software publishers 

specified independent of specific trust providers. Multiple „ public FmaU ^ me PKCS #7 si S^^ data structure must 

trust providers may share a common implementation to ? ntaui J"? Exl f malI ? ata attribute that contains a 

extract trust material from these subject formats and digest ^ ° f bcm ^ OI T _ 0 

the relevant portions of the data stream. This separation th J f ^ ron ** ons t API returns SUCCESS to 

allows trust providers to verify the trustworthiness ofTdata jf, Dg apP ^° D * • ^T^' * ? "T™ ™ 

. f ■ r . , .... provided, a user interface is displayed providing information 

stream of a jpven format, without building knowledge of M ODtained ^ valid ^ fJ taoaUdns ^ 

subject formats into each trust provider. Instead, trust pro- path of the subject file. If the user confirms acceptance of the 

viders share other common components (that are also trusted fi] e , me API also returns SUCCESS; if the user does not 

^Sa^^h^- ^ ^ ^ am * ^^^A^ acceptance, returns a distinguished error code. 

£T2?5£ tmn^lTZ ** ^ff^*~ H *™Z described mustrated te P^P les of our 

Type field of the ACTIONDATA structures defined above, 35 invention with reference to an illustrated embodiment, it will 

111 be recognized that the illustrated embodiment can be modi- 

fclefine WIN_TRUST_SUBJTYPE_RAW_FILE fied in arrangement and detail without departing from such 

#define WIN„TRUST_SITBJTYPE_PE_.IMAGE principles. It should be understood that the programs, 

^define WIN_TRUST_SUBJTYPE_OLE_STORAGE processes, or methods described herein are not related or 

For all of these subject types, the same data structure is 40 J™ 1 " 1 to ^ particular type of computer apparatus, unless 

required in the Subject parameter of the ACITONDATA indicated otherwise. Various types of general purpose or 

structures. This structure is: specialized computer apparatus may be used with or perform 

typedefstruct_WIN TRUST SUBJECT FILE f operations in accordance with the teachings described 

herein. Elements of the illustrated embodiment shown in 

HANDLE IiFile; 45 software may be implemented in hardware and vice versa. 

LPCWSTR IpPath; In view of the many possible embodiments to which the 

}WIN„TRUST_SUBJECT_FILE, *LPWIN_ principles of our invention may be applied, it should be 

TRUST_SUBJECT_FILE; recognized that the detailed embodiments are illustrative 

The hFile element of the structure is optional. If hFile is only and should not be taken as limiting the scope of our 

provided, trust providers are expected to use this file handle so invention. Rather, we claim as our invention all such 

to read the subject as a performance optimization. If hFile is embodiments as may come within the scope and spirit of the 

set to the value IWAUD__HANDLE_VALUE (defined in following claims and equivalents thereto. 

WINBASE.H) then the trust provider will open the subject We claim: 

using the IpPath field. 1. In a local computer system, a method of digitally 

The IpPath element of this structure is mandatory and 55 signing an executable file for distribution over a network 

includes the path of the subject being verified. The string from the local computer system to a remote computer 

may be used for the purpose of opening the file to read it, and system by performing a calculation on contents of the 

optionally for prompting the user for additional information executable file at the local computer system, wherein the 

about the file. executable file is of an executable file format defining a 

The caller may specify both fields in the structure, but 60 plurality of fields, wherein at least one field has a value 

provide a different string for IpPath than was used to obtain modifiable to add a new section elsewhere in the executable 

the HFILE handle. The IpPath string is not validated to file and is designated in the calculation at the local computer 

ensure consistency with the open handle or the name that the system as excluded when performing the calculation to 

subject may "expect" to have. This gives the caller the generate a digital signature for the executable file, the 

option of storing a subject data stream under a temporary 65 method comprising: 

name during the trust verification phase, and presenting the generating the digital signature for the executable file at 

original file path in any user interface dialog. the local computer system by performing the calcula- 
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tion on at least one of the plurality of fields, excluding 
the field having a value modifiable to add a new section 
elsewhere in the executable file and designated in the 
calculation at the local computer system as excluded 
when performing the calculation to generate a digital 
signature for the executable file out of the fields from 
the calculation; 

adding a new section to the executable file at the local 
computer system by modifying the value of the field 
having a value modifiable to add a new section else- 
where in the executable file and designated in the 
calculation at the local computer system as excluded 
when performing the calculation to generate a digital 
signature for the executable file; and 

at the local computer system, placing the digital signature 
in the new section to embed the digital signature in the 
executable file. 

2. A computer-readable medium having computer- 
executable instructions for performing the method recited in 
claim 1. 

3. The method of claim 1 wherein 

the executable file comprises an attributes-count field, the 

attributes-count field indicative of how many attributes 

are in the executable file; 
the designated field having a value modifiable to add a 

new section elsewhere in the executable file is the 

attributes-count field; 
said adding increments the attributes-count field to add a 

new attribute to the executable file, wherein the new 

section comprises the new attribute; and 
said placing places the digital signature into the new 

attribute of the executable file. 

4. The method of claim 1 wherein said generating calcu- 
lates a hash for the executable file, excluding the designated 
field having a value modifiable to add a new section else- 
where in the executable file from the hash. 

5. In a local computer system, a method of digitally 
signing an executable file for distribution over a network 
from the local computer system to a remote computer 
system by performing a calculation on contents of the 
executable file at the local computer system, wherein the 
executable file is of an executable file format defining a 
header having a plurality of fields and accommodating 
modification of a value of a header field in the header to add 
a new section to the executable file, wherein the header field 
is designated in the calculation at the local computer system 
as excluded when performing the calculation to generate a 
digital signature for the executable file, the method com- 
prising: 

generating the digital signature for the executable file at 
the local computer system by performing the calcula- 
tion on at least a portion of the executable file outside 
the header and at least a portion of the header, exclud- 
ing the designated header field out of the fields in the 
header from the calculation; 

adding a new section to the executable file at the local 
computer system by modifying the value of the desig- 
nated header field; and 

at the local computer system, placing the digital signature 
in the section to embed the digital signature in the 
executable file; 

wherein the generating step calculates a hash for the 
executable file, excluding the designated header field 
from the hash; 

wherein the generating step further excludes information 
for localizing the executable file from the hash. 
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6. In a local computer system, a method of digitally 
si gning an executable file for distribution over a network 
from the local computer system to a remote computer 
system by performing a calculation on contents of the 
executable file at the local computer system, wherein the 
executable file is of an executable file format defining a 
header having a plurality of fields and accommodating 
modification of a value of a header field in the header to add 
a new section to the executable file, wherein the header field 
is designated in the calculation at the local computer system 
as excluded when performing the calculation to generate a 
digital signature for the executable file, the method com- 
prising: 

generating the digital signature for the executable file at 
the local computer system by performing the calcula- 
tion on at least a portion of the executable file outside 
the header and at least a portion of the header, exclud- 
ing the designated header field out of the fields in the 
header from the calculation; 
adding a new section to the executable file at the local 
computer system by modifying the value of the desig- 
nated header field; and 
at the local computer system, placing the digital signature 
in the section to embed the digital signature in the 
executable file; 
wherein the generating step calculates a hash for the 
executable file, excluding the designated header field 
from the hash; 
wherein the generating step further excludes information 

for debugging the executable file from the hash. 
7. In a computer system, a method of digitally signing an 
executable file comprising a plurality of constants in a 
constant pool, a constant-pool-count field indicating how 
many constants are in the constant pool and incrementable 
to add a new constant to the constant pool, a plurality of 
35 attribute-info fields, and an attributes-count field indicating 
how many attribute-info fields are in the file and increment- 
able to add a new attribute-info field, the method compris- 
ing: 

generating a hash for the file, excluding from the hash the 
constant-pool-count field incrementable to add a new 
constant to the constant pool and the attributes-count 
field incrementable to add a new attribute-info field, 
including in the hash at least one of the attribute-info 
fields and at least one of the constants in the constant 
pool; 

encrypting the hash to form part of a digital signature; 
adding a new attribute-info field labeled as a digital 

signature to the attribute-info fields by performing the 

steps: 

(a) incrementing the constant-pool-count field incre- 
mentable to add a new constant to the constant pool, 
wherein the constant-pool-count field is excluded 
from the hash; 

(b) placing a constant indicative of a digital signature in 
the constant pool; 

(c) incrementing the attributes-count field increment- 
able to add a new attribute-info field, wherein the 
attributes-count field is excluded from the hash; and 

(d) storing a reference to the constant indicative of a 
digital signature in the new attribute-info field added 
by incrementing the constant-pool-count field; and 

placing the digital signature in the new attribute-info field 
added by incrementing the attributes-count to embed 
the digital signature in the executable file. 
8. A computer-readable medium having computer- 
executable instructions for performing the steps recited in 
claim 7. 
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9. In a first computer system, a method of confirming a 
digital signature embedded in an executable file, wherein the 
executable file comprises a plurality of elements, and a 
number-of-elements field, the number-of-elements field 
indicative of how many elements are in the file, wherein one 5 
of the elements serves as a digital signature for the execut- 
able file, the method comprising: 

generating calculated identifying information by perform- 
ing a calculation on a set of fields and elements in the 
executable file, excluding the number-of-elements field 10 
and the element serving as the digital signature from 
the calculation, including in the calculation at least one 
of the plurality of elements; 

extracting, from the digital signature, provided identify- 
ing information having been generated by performing 15 
the calculation on a same set of fields and elements in 
the executable file at a second computer system, 
wherein the calculation performed at the second com- 
puter system excluded the number-of-elements field 
and the element serving as the digital signature from 
the calculation and included in the calculation at least 
one of the plurality of elements; and 

comparing the provided identifying information with the 
calculated identifying information to determine 
whether the digital signature is valid. 

10. A computer-readable medium having computer- 
executable instructions for performing the steps recited in 
claim 9. 

U. The method of claim 9 wherein 

the generating step calculates a hash for the file, excluding 
the number-of-elements field and the element serving 
as the digital signature from the hash; and 

the comparing step determines the digital signature is 
valid if the provided identifying information and the 
calculated identifying information are identical. 

12. The method of claim 11 wherein the file further 
comprises an encrypted hash and an encrypted publisher 
key, the method further comprising: 

decrypting the encrypted publisher key with a remotely- 
available agency key to provide an unencrypted pub- 
lisher key; 

decrypting the encrypted hash with the unencrypted pub- 
lisher key to provide an unencrypted hash serving as 
the provided identifying information. 

13. The method of claim 11 wherein 
the file is of the Common Object File Format and com- 
prises a CertificateTable field and a certificate table; 

the elements are certificates in the file referenced by the 
certificate table; 

the certificate table is of a size indicated by the Certifi- 
cateTable field; 

the number-of-elements field is in the CertificateTable 
field; 

the element serving as the digital signature is a certificate 

referenced by the certificate table; and 
the generating step further excludes the certificate table 

from the hash. 

14. In a first computer system, a method of confirming a 60 
digital signature embedded in an executable file, wherein the 
executable file comprises a header comprising a plurality of 
fields, a plurality of elements, and a number-of-elements 
field in the header, the number-of-elements field indicative 
of how many elements are in the file, wherein one of the 65 
elements serves as a digital signature, the method compris- 
ing: 



generating calculated identifying information by perform- 
ing a calculation on a portion of the executable file, 
excluding the number-of-elements field and the ele- 
ment serving as the digital signature from the 
calculation, including in the calculation at least one 
field from the header; 
extracting, from the digital signature, provided identify- 
ing information having been generated by performing 
the calculation on the portion of the executable file at 
a second computer system; and 
comparing the provided identifying information with the 
calculated identifying information to determine 
whether the digital signature is valid; 
wherein the generating step calculates a hash for the file, 
excluding the number-of-elements field and the ele- 
ment serving as the digital signature from the hash; and 
the comparing step determines the digital signature is 
valid if the provided identifying information and the 
calculated identifying information are identical; 
wherein the file is of the Common Object File Format and 
comprises a CertificateTable field and a certificate 
table; 

the elements are certificates in the file referenced by the 

certificate table; 
the certificate table is of a size indicated by the Certifi- 
cateTable field; 
the number-of-elements field is in the CertificateTable 
field; 

the element serving as the digital signature is a certificate 

referenced by the certificate table; and 
the generating step further excludes the certificate table 

from the hash; 
wherein the file comprises a resource table; and 
the generating step further excludes the resource table 
from the hash. 

15. In a computer system, a method of confirming a digital 
signature embedded in a file of a Java class file format, 

40 wherein the file comprises a plurality of constants in a 
constant pool, a constant-pool-count field, the constant- 
pool-count field indicative of how many constants are in the 
constant pool and incrementable to add a new constant to the 
constant pool, a plurality of fields defining a set of attributes, 
and an attributes-count field, the attributes-count field 
indicative of how many attributes are in the file and incre- 
mentable to add a new attribute to the set of attributes, 
wherein one of the attributes in the set of attributes serves as 
a digital signature and one of the constants in the constant 
50 pool is a constant labeling a digital signature, the method 
comprising: 

extracting a first hash from the attribute serving as a 

digital signature; 
calculating a second hash for the file, excluding the 
constant labeling a digital signature, the constant-pool- 
count field incrementable to add a new constant to the 
constant pool, the attribute serving as a digital 
signature, and the attributes-count field incrementable 
to add a new attribute to the set to the set of attributes 
from the second hash, including at least one of the 
attributes in the set of attributes in the second hash; and 
comparing the first hash and the second hash to determine 
if the first hash is identical to the second hash, thereby 
determining whether the file has been modified since it 
was signed with the digital signature. 

16. The method of claim 15 wherein the extracting step 
comprises: 



30 



35 



45 



55 



US 6367,012 Bl 



35 



36 



10 



15 



decrypting an encrypted key residing in the file to gen- 
erate an decrypted key; and 

decrypting an encrypted hash residing in the file with the 
decrypted key to provide the first hash. 

17. A method of distributing an executable file, wherein 
the executable file comprises a plurality of elements and a 
number-of-elements field indicative of how many elements 
are in the file and incrementable to add a new element to the 
file, the method comprising: 

at a first computer, performing the steps: 

(a) generating a digital signature for the executable file 
by calculating a first hash for the executable file, 
excluding the number-of-elements field increment- 
able to add a new element to the file from the first 
hash, and including at least one of the plurality of 
elements in the first hash; 

(b) adding a digital signature element to the executable 
file by incrementing the number-of-elements field 
incrementable to add a new element to the file, 
wherein the number-of-elements field was excluded 20 
when generating the digital signature for the execut- 
able file; and 

(c) placing the digital signature in the digital signature 
element added by incrementing the number-of- 
elements field to embed the digital signature in the 
executable file; and 

at a second computer, performing the steps: 

(d) calculating a second hash for the executable file, 
excluding the number-of-elements field and the digi- 
tal signature element from the second hash, and 
including the at least one of the plurality of elements 
in the second hash; 

(e) extracting the first hash from the digital signature 
element; and 

(f) comparing the first hash with the second hash to 
determine whether the executable file was modified 
after the digital signature was embedded therein. 

18. The method of claim 1 further comprising: 
labeling the new section with an identifier recognized at 

the remote computer system as a section to be excluded 
at the remote computer system from calculations veri- 
fying the embedded digital signature. 

19. The method of claim 3 wherein the executable file is 
of a file format for Java class files. 

20. The method of claim 7 further comprising: 
labeling the new attribute-info field with an attribute name 

recognized at a remote computer system as an attribute 
to be excluded from calculations verifying the embed- 
ded digital signature at the remote computer system. 

21. The method of claim 15 wherein the calculating step 
calculates the second hash for the file using a one pass 
technique, visiting each field in the file and included in the 
second hash exactly once to calculate the second hash. 

22. The method of claim 15 wherein the calculating step 
further includes in the second hash the attributes-count field 
decremented by one and the constant-pool-count field dec- 
remented by one. 

23. The method of claim 15 further comprising: 
ottennining whether the file contains a signature; wherein 

the calculating step further includes in the second hash 
the attributes-count field decremented by one and the 
constant-pool-count field decremented by one when it 
is determined that the file contains a signature. 



24. In a computer system, a method of performing hash 
calculations to generate a hash value for a file to ensure hash 
invariance irrespective of the presence of a signature in the 
file, wherein the file comprises a plurality of fields and a set 
of a plurality of elements, at least one of the fields tracking 
how many elements are in the set and incrementable to add 
an element to the set of a plurality of elements, the method 
comprising: 

to generate the hash value for the file, performing a 
hashing function on at least one of the plurality of fields 
during hash calculations; 
to generate the hash value for the file, performing a 
hashing function on at least one of elements in the set 
of a plurality of elements during hash calculations; 
when generating the hash value for the file, excluding 
from bash calculations the at least one of the fields 
tracking how many elements are in the set and incre- 
mentable to add an element to the set of a plurality of 
elements; and 

when generating the hash value for the file, excluding 
from hash calculations an element in the set of a 
plurality of elements tagged as a digital signature 
element, if any. 

25. The method of claim 24 wherein 
the file is of a Java class format comprising a constant 

pool; 

the at least one of the fields tracking how many elements 
are in the set and incrementable to add an element to the 
set of a plurality of elements is an attributes-count field; 
and 

the element in the set of a plurality of elements tagged as 
a digital signature element, if any, is tagged using a 
constant in the constant pool. 

26. The method of claim 4 wherein said generating further 
excludes information for localizing the executable file from 
the hash. 

27. The method of claim 7 wherein said generating further 
excludes information for localizing the executable file from 
the hash for the file. 

28. The method of claim 1 wherein said generating 
produces a hash for the executable file, wherein the execut- 
able file is published by a publisher and certified by a 
certification agency, wherein the publisher has a publisher's 
private key and a publisher's public key corresponding to 
the publisher's private key and the certification agency has 

50 an agency's private key and an agency's public key corre- 
sponding to the agency's private key, the method further 
comprising: 

generating a publisher's digital certificate comprising the 

hash encrypted with the publisher's private key; 
generating an agency's digital certificate comprising the 
publisher's public key encrypted with the agency's 
private key; 

wherein the hash can be retrieved from the publisher's 
digital certificate by decrypting the encrypted publish- 
er's public key with the agency's public key and 
decrypting the encrypted hash with the decrypted pub- 
lisher's public key. 
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UNITED STATES PATENT AND TRADEMARK OFFICE 

CERTIFICATE OF CORRECTION 

PATENT NO. : 6,367,012 Bl Page 1 of 2 

DATED : April 2, 2002 

INVENTOR(S) : Atkinson et al. 



It is certified that error appears in the above-identified patent and that said Letters Patent is 
hereby corrected as shown below: 



Title Page, 

Item [56], OTHER PUBLICATIONS, "http://swissnet^ 

htnl/22" should read - http://swissnet.alnut.eoV^ -. 
Column 13, 

Line 26, "referred" should read - preferred --. 
line 38, "DEBGUG" should read - DEBUG -. 

Column 14. 

Line 67, "NT" should read -- NT™ --. 
Column 17, 

Line 17, "NT)" should read -- NT™) --. 
Line 33, "NT" should read -- NT™ --. 

Column 19. 

Lines 12 and 13, "debug" should read -- .debug -. 
Column 20. 

Line 3, "debug" should read - .debug --. 

Line 49, "class" should read - .class --. 

Line 58, "poolcount" should read - pool_count — . 

Column 21. 

line 7, before the heading "GenericAltributeinfo", the following should appear: 

- Attributes have the following format: 

lines 24, 36, 47 and 54, "class" should read - .class -. 

Column 22. 

line 3, "except in a two cases" should read - except in two cases -. 
Lines 58-59, after "signerlnfos Signerlnfos}" the following should appear: 

- DigestAlgorithmldentifiers ::=SET OF DigestAlgorithmldentifier 
Signerlnfos ::=SET OF Signerlnfo -. 



UNITED STATES PATENT AND TRADEMARK OFFICE 

CERTIFICATE OF CORRECTION 



PATENT NO. 

DATED 

INVENTOR(S) 



6,367,012 Bl 
April 2, 2002 
Atkinson et al. 



Page 2 of 2 



It is certified that error appears in the above- identified patent and that said Letters Patent is 
hereby corrected as shown below: 



Column 23. 

Line 67, "class" should read -- .class 



Signed and Sealed this 



Eleventh Day of March, 2003 




JAMES E. ROGAN 
Director of the United States Patent and Trademark Office 



